[レポート]Embrace DevOps by building a self-service environment at scale with CDK #reinvent

はじめに

CX事業本部の佐藤智樹です、今回はre:InventにてCDK(Python)でServiceCatalogを作成するWorkshopに参加したのでこちらについてレポートします。

In this builders’ session, learn how to define, configure, and deploy AWS Service Catalog with the AWS CDK in a single repository. Utilizing a code-first approach, define your governance and security controls directly alongside the applications and resources end users are deploying. Find out how to distribute managed templates across multiple accounts and regions, allowing end users to provision resources within appropriate permissions boundaries. Using the powerful abstractions in the AWS CDK, learn how to customize code in a modular way and take advantage of features like type checking and IDE integrations to accelerate the development process. You must bring your laptop to participate.

このビルダーズセッションでは、単一のリポジトリでAWS CDKを使用してAWS Service Catalogを定義、設定、およびデプロイする方法を学習します。コードファーストのアプローチを利用して、エンドユーザーがデプロイするアプリケーションやリソースと一緒に、ガバナンスとセキュリティコントロールを直接定義します。複数のアカウントとリージョンに管理されたテンプレートを配布し、エンドユーザが適切な権限の範囲内でリソースをプロビジョニングできるようにする方法を説明します。AWS CDKの強力な抽象化機能を使用して、モジュール方式でコードをカスタマイズする方法を学び、型チェックやIDE統合などの機能を活用して、開発プロセスを加速させる方法を学びます。参加にはノートPCの持参が必要です。

登壇者

• Luis Rodriguez Montilla氏
• Brad Hankel氏
• Ron Davis氏
• Tyler Southwick氏
• Alan Delucia氏

5つのテーブルに分かれて、最初のCDKやServiceCatalogに関する説明のみLuis氏が実施し、その後は各テーブル1名がワークショップを進行していました。

タイトル

ワークショップに関する説明

前半10分程度でServiceCatalogがなぜ必要なのか、CDKをなぜ使うのかについて言及されていました。

このセッションではAWS CDKを使ったServiceCatalogのProductの設定やデプロイをどのように行うのかについて学びます。そして、コードファーストのアプローチを使って、ガバナンスとセキュリティを定義していきます。最後にAWS CDKのコンストラクトとアブストラクションの使い方を学びます。

ワークショップの前に、なぜ企業がServiceCatalogを使う必要があるのかご紹介します。AWSで運用しているとき、お客様は投資に対するリターンを見ています。インフラにおけるそのものの生産性、運用の回復力の向上、彼らのビジネスの俊敏性、二酸化炭素排出量の削減を実現しているのです。

しかしながら、どのようにスケールアップする計画の運用が見えていますか？まず、基盤となるガバナンスとコンプライアンスを確立し、新しいアプリケーションや既存のワークロードをデータセンターからクラウドに移行して構築し運用を開始します。運用を開始すると、運用管理をいかにして簡素化し、統合的なアプリケーション監視を実施し、品質を改善し、より優れた自動化を実現するための検討を始めます。

ServiceCatalogがなぜこのようなことに適しているかというと、ServiceCatalogはあなたの環境と、あなたが市場に出そうとしている価値の間に位置するからです。ServiceCatalogは、消費者、内部顧客、ビルダーのためのセルフサービスによる製品構築を可能にするからです。同時に、ガバナンスの必要なセキュリティチームは、ビルダー達に向けて、抽象化されたコントロールやアクセス管理などを考案できます。

。

管理者として、ポートフォリオを作成し、それをさまざまなアカウントや組織単位で共有し、共有プロダクトやセルフサービス機能を使用し始めることができるユーザーを持ち、コンプライアンスとガバナンスを適用し、管理者の立場から。アクセス管理、製品への作業、タグオプションの適用、IAMロールによる権限管理などが実現できます。

ではAWS CDKはどのように関わってくるのでしょうか？CDKはL2 Constructと呼ばれるリソースを抽象化した状態で扱うことができます。CDK自体はPython、JavaScript、またはJavaなどで定義し、デプロイするとServiceCatalogのPortfolioが展開されユーザはProductを使うことができます。

これはどのようにパイプラインに統合するのでしょうか。コードをGitなどにコミットし、パイプラインを通じて段階的に古いコードを更新します。これが完了すると、異なるアカウントや異なるリージョンに向けてServiceCatalogのPortfolioが展開できます。左のアカウントは組織側が設定し、右側をビルダーが使うことでガバナンスとコントロールが適用できます。

またCDK importを使うことで、ビルダーがサービスをプロビジョニングする際に、より開発者体験の良くサービスを提供できます。以前まではYAMLやJSONのテンプレートを構築する人がいて、テンプレートを作成することになりました。今は、CDK importを使うことで両方から製品のプロビジョニングを始められるようになりました。

これは何を意味するのでしょうか。コスト面では、エンドユーザーであるコンシューマーがこの製品にアクセスすることで、基本的にインフラに基づくあらゆる抽象化が可能になり、ビルダーの立場からは、インフラの定義にサービスメンバーのProductを使用することができます。

(佐藤補足：ServiceCatalogのPortfolio(リソース展開用のテンプレートなどが含まれるもの)はCloudFormationのテンプレートとして各アカウントに配られるため、管理者側がServiceCatalogをCDKで作っていても、ビルダー側はServiceCatalog上ではCDKのコードがわかりません。このセッションではその対策としてCDK import(現状のリソース設定をCDKに取り込む機能)を使って管理者/ビルダーが相互にServiceCatalog内の製品の状況を取得し更新できることが説明されていました。)

ここでは、Amazon VPCを使用した空のスタックを例として挙げています。RDSなどAWSリソースをJava、JavaScriptなどの言語から好きなものを使ってデプロイすることができます。

実際のワークショップ

ワークショップの内容としては、CDKをPythonで記述しServiceCatalogのPortfolioやProductを作成する基本的な部分が紹介されました。実装はCloud9上で行い、Productの展開される様子をシングルアカウントで確認できました。

ワークショップはAWS Workshop Studioで実行されておりイベント終了後はワークショップページがアクセスできなくなるため今回はこちらには掲載できません。今後公開などされた際は追記します。

所感

基本的に知っている内容ではあったのですが、管理者側とビルダー側がCDK importで設定を共有しあうというアイデアはとても面白く、単なるガバナンスだけでなくインフラリソース周りの効率的な展開のために有効かもしれないと感じました。

後、CDKでPythonを初めて使ったのでなかなか新鮮な体験でした。ServiceCatalog自体初めての方は、なぜServiceCatalogが必要でCDKを使うのかがじっくり話されていたので参考になるかと思います。